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(57) Abstract 

Protocols and architecture for secure virtual private networks. Intraenterprise data communications are supported in a secure manner 
over the Internet or other public network space with the implementation of secure virtual private networks. Members of a virtual private 
network group exchange data that may be compressed, encrypted and authenticated, if the exchange is between members of the group. 
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AN APPARATUS FOR IMPLEMENTING VIRTUAL PRIVATE NETWORKS 
BACKGROUND OF THE INVENTION 

1. Related Information 

The present invention is related to the one described in Copending U.S. Patent 
5 application entitled " Architecture for Virtual Private Networks" Serial Number 

08/874,090 [Attorney Docket No. 20155-701], assigned to the assignee of the present 
invention and filed concurrently herewith. 

2. Field of the Invention 

The present invention relates to the field of data communications. More 
1 0 particularly, the present invention relates to techniques for implementing secure 
virtual private networks over public or otherwise insecure data communications 
infrastructures. 

3. Background 

In recent years organizations have come to rely heavily on the ability to 
1 5 transmit electronic data between members of the organization. Such data typically 
includes electronic mail and file sharing or file transfer. In a centralized, single site 
organization, these transfers of electronic data are most commonly facilitated by a 
local area network (LAN) installed and operated by the particular enterprise. 

Preventing unauthorized access to data traversing an enterprise' s LAN is 
20 relatively straightforward. This applies to both unauthorized accesses by members of 
the enterprise and, more importantly, to third parties on the outside. As long as 
intelligent network management is maintained, unauthorized accesses to data 
traversing an enterprise's internal LAN are relatively easily avoided. It is when the 
enterprise spans multiple sites that security threats from the outside become a major 
25 concern. 

For distributed enterprises that desire the conveniences of the above-described 
electronic data transfers, there are several options that exist today, but each with 
associated disadvantages. The first option is to interconnect the offices or various 
sites with dedicated, or private communications connections often referred to as 
30 leased lines. This is the traditional method organizations use to implement a wide 
area network (WAN). The disadvantages of implementing an enterprise owned and 
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controlled WAN are obvious: they are expensive, cumbersome and frequently 
underutilized if they are established to handle the peak capacity requirements of the 
enteiprise. The obvious advantage to this approach is that the lines are dedicated for 
use by the enterprise and are therefore secure, or reasonably secure from 
5 eavesdropping or tampering by intermediate third parties. 

An alternative to the use of dedicated communications lines in a wide area 
network is for an enterprise to handle intersite data distributions over the emerging 
public network space. Over recent years, the Internet has transitioned from being 
primarily a tool for scientists and academics to a mechanism for global 

1 0 communications with broad ranging business implications. The Internet provides 
electronic communications paths between millions of computers by interconnecting 
the various networks upon which those computers reside. It has become 
commonplace, even routine, for enterprises, even those in nontechnical fields, to 
provide Internet access to at least some portion of the computers within the enterprise. 

1 5 For many businesses this facilitates communications with customers, potential 
business partners as well as the distributed members of the organization. 

Distributed enterprises have found that the Internet is a convenient tool to 
provide electronic communications between members of the enterprise. For example, 
two remote sites within the enterprise may each connect to the Internet through a local 

20 Internet Service Provider (ISP). This enables the various members of the enterprise to 
communicate with other sites on the Internet including those within their own 
organization. The limiting disadvantage of using the Internet for intra-cnterprise 
communications is that the Internet is a public network space. The route by which 
data communication travel from point to point can vary on a per packet basis, and is 

25 essentially indeterminate. Further, the data protocols for transmitting information 
over the various networks of the Internet are widely known, and leave electronic 
communications susceptible to interception and eavesdropping with packets being 
replicated at most intermediate hops. An even greater concern arises when it is 
realized that communications can be modified in transit or even initiated by 

30 impostors. With these disconcerting risks, most enterprises are unwilling to subject 
their proprietary and confidential internal communications to the exposure of the 
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public network space. For many organizations it is common today to not only have 
Internet access provided at each site, but also to maintain the existing dedicated 
communications paths for internal enterprise communications, with all of the 
attendant disadvantages described above. 
5 While various encryption and other protection mechanisms have been 

developed for data communications, none completely and adequately addresses the 
concerns raised for allowing an enterprise to truly rely on the public network space for 
secure intra-enterprise data communications. It would be desirable, and is therefore 
an object of the present invention to provide such mechanisms which would allow the 
1 0 distributed enterprise to rely solely on the public network space for intra-enterprise 
communications without concern for security risks that presently exist. 

SUMMARY OF THE INVENTION 
From the foregoing it can be seen that it would be desirable and advantageous 
to develop protocols and architecture to allow a single organization or enterprise to 
1 5 rely on the public network space for secure intraorganizational electronic data 

communications. The present invention is thus directed toward the protocols and 
architecture for implementing secure virtual private networks over the Internet or 
other public network apparatus. The architecture of the present invention introduces a 
site protector or virtual private network (VPN) unit which moderates data 
20 communications between members of a defined VPN group. In accordance with one 
embodiment of the present invention, the site protector resides on the WAN side of 
the site's router or routing apparatus which is used to connect the enterprise site to the 
Internet. In alternative embodiments, the site protector will reside on the LAN side of 
the router. The essential point for all embodiments is that the site protector be in the 
25 path or all relevant data traffic. 

To ensure secure data communications between members of the same VPN 
group, the site protector or VPN Unit implements a combination of techniques for 
data packet handling when packets are to be sent between members of the group. The 
packet handling processes include various combinations of compression, encryption 
30 and authentication, the rules for each of which may vary for members of different 
groups. For each group defined as a virtual private network, the various parameters 
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defining the compression, encryption and authentication are maintained in lookup 
tables in the associated VPN Units. The lookup tables maintain information not only 
for fixed address members of the group but support is also provided for remote 
clients. This ability allows remote users to dial into a local Internet Service Provider 
and still maintain membership in a virtual private network group for secure 
communications over the Internet with other members of the group. In the case of a 
remote client, the site protector may, in one embodiment, be simulated by software 
running on the remote client. 

In other aspects of the present invention, the VPN Units or site protectors may 
be dynamically configured to add or subtract members from the virtual private 
network group or recognize their movement, or change other parameters affecting the 
group. Various other packet handling aspects of the invention include addressing the 
problem of some data packets growing too large by the inclusion of encryption and 
authentication information. Another packet handling aspect provides a mechanism for 
Internet communications which hides information identifying the source and 
destination of the data packet. In this aspect of the present invention, the VPN Units 
are treated as the source and destination for the Internet communication data packets 
with the VPN Units encapsulating the source and destination addresses of the 
endstations. 

There is also disclosed a hardware architecture and implementation for a VPN 
Unit. This embodiment is one designed to reside on the WAN side of a given site's 
router. In the illustrated embodiment, a combination of computer hardware and 
software are provided for carrying out the processes of the VPN apparatus for 
compression, encryption and authentication under the direction of a microprocessor. 
25 BRIEF DESCRIPTION OF THE DRAWINGS 

The objects, features and advantages of the present invention will be apparent 
from the following detailed description,, in which: 

Figure 1 illustrates a prior art configuration for an exemplary enterprise's 
intraenterprise communication architecture. 



15 



20 
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Figure 2 illustrates an enterprise communication scenario in accordance with 
the present invention utilizing the Internet or other public network space as the vehicle 
for conveying messages between members of a virtual private network. 

Figure 3 illustrates a flow diagram for the handling of a packet being 
5 transmitted from one member of a virtual private network group to another member 
over the Internet. 

Figure 4 illustrates the handling of a data packet received over the Internet by 
one member of a virtual private network group from another member. 

Figure 5 illustrates graphically the life cycle of a data packet being sent from 
10 one member of a virtual private network group to another over the Internet. 

Figure 6 illustrates an alternate life cycle of a data packet being sent from one 
member of a virtual private network group to another over the Internet where the 
source and destination addresses of the group members are also concealed. 

Figure 7 illustrates an architectural block diagram for an implementation of a 
1 5 virtual private network unit in accordance with one embodiment of the present 
invention. 

Figure 8 illustrates a more detailed block diagram for one implementation of a 
virtual private network unit in accordance with one embodiment of the present 
invention. 

20 DETAILED DESCRIPTION OF THE INVENTION 

An apparatus and apparatus are disclosed for implementing secure virtual 
private networks for enterprise communications over the Internet or other public 
network space. Although the present invention is described predominantly in terms of 
utilizing the Internet as a communications medium, the concepts and methods are 

25 broad enough to accomplish the implementation of secure virtual private networks 
over other public or insecure communications media. Throughout this detailed 
description, numerous specific details are set forth such as particular encryption or key 
management protocols, in order to provide a thorough understanding of the present 
invention. To one skilled in the art, however, it will be understood that the present 

30 invention may be practiced without such specific details. In other instances, well- 
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known control structures and apparatus components have not been shown in detail in 
order not to obscure the present invention. 

In many instances, components implemented by the present invention are 
described at an architectural, functional level. Many of the elements may be 
5 configured using well-known structures, particularly those designated as relating to 
various compression or encryption techniques. Additionally, for logic to be included 
within the apparatus of the present invention, functionality and flow diagrams are 
described in such a manner that those of ordinary skill in the art will be able to 
implement the particular methods without undue experimentation. It should also be 

1 0 understood that the techniques of the present invention may be implemented using a 
variety of technologies. For example, the virtual private network unit or site protector 
to be described further herein may be implemented in software running on a computer 
apparatus, or implemented in hardware utilizing either a combination of 
microprocessors or other specially designed application specific integrated circuits, 

1 5 programmable logic devices, or various combinations thereof. It will be understood 
by those skilled in the art that the present invention is not limited to any one particular 
implementation technique and those of ordinary skill in the art, once the functionality 
to be carried out by such components is described, will be able to implement the 
invention with various technologies without undue experimentation. 

20 Referring now to Figure 1 there is shown a traditional scenario for intra- 

enterprise data communications for a distributed organization. In this illustration of 
an exemplary organization configuration, the enterprise consists of a headquarters 
location 105 with additional sites or branches 1 10 and 1 12, respectively. In modern 
organizations, such as the exemplary one of Figure 1, the headquarters' site 105 as 

25 well as the branch sites 1 1 0 and 1 1 2 may each comprise numerous personnel, many of 
whom are provided with computers or work stations with network access. The 
internal network configurations at the headquarters for branches may take many forms 
including one or several local area networks (LANs). For intersite communications 
between headquarters and the branches, dedicated or leased communications lines 115 

30 and 120 may be provided. In addition, an optional dedicated communications path 
125 may be provided between the branches 1 10 and 1 12. As an alternative to the 
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optional dedicated communications line 125 between the branches, data packets 
between branch 1 10 and branch 1 12 may be routed through the headquarters' network 
equipment. 

In addition to the dedicated communications lines between the headquarters 
5 and the various branches, it is common today to provide computer users within an 
organization access to the Internet for electronic mail to external parties as well as for 
doing various types of research over the Internet using such tools as the World Wide 
Web, etc. As shown in Figure 1, the usual scenario where the headquarters' site 105 
and the branches 1 10 and 1 12 are each separately provided with direct access to 
10 Internet Service Providers 130, 133 and 136. respectively. This facilities the users at 
the various sites with their access to the Internet for the above purposes. In an 
alternate configuration, it may be that only the headquarters site 105 is provided with 
access to an Internet service provider 130 and that users of the computers of the 
branch sites 1 10 and 1 12 will connect to the Internet through headquarters via their 
15 dedicated communications paths 115 and 120. The downside to this alternate 

configuration is that it greatly increases the bandwidth utilization on the dedicated 
lines, perhaps to the point of saturation. An advantage is that only one gateway to the 
Internet need be provided for the organization which simplifies enforcing security 
constraints on connections to the outside world. 
20 In the exemplary organization 1 00, it is also shown that in some circumstances 

it may be desirable to allow customers or other business partners to dial in directly to 
the computer network of the organization. In Figure 1 it is illustrated that the 
customer 1 40 may in fact carry out such communications over a communications path 
145 which may be a dedicated line provided between the customer and the 
25 organization for the customer's convenience. The path 145 may also be a dial-up line 
which the customer might use only sporadically. Consistent with the emerging use of 
the Internet and its popularity, the customer 140 is shown having its own Internet 
connection through ISP 148. 

Finally, there is shown in Figure 1 that it is frequently desirable for other 
30 members of the enterprise who may be on the road or working from home or other 

remote locations to exchange data with other members of the enterprise. There is thus 
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shown remote clients 150 and 155 communicating with the headquarters over long 
distance telephone lines 1 57 and 1 58. This example assumes that the remote clients 
are in a truly remote location from the headquarters. The remote clients 150 and 1 55 
are also respectively shown having local access to the Internet through local ISPs 160 
and 165. 

The above description of an enterprises data communications configuration 
according to Figure 1 illustrates the disadvantages described in the previous section. 
These disadvantages are eliminated by implementation of the present invention as 
illustrated generally with reference to Figure 2. In the enterprise network 
communication configuration 200 illustrated in Figure 2, the headquarters 1 05, first ' 
branch 1 10 and second branch 1 12 of the organization are illustrated in a more 
detailed logical way then presented in Figure 1. Thus, the headquarters 105 is 
illustrated with three endstations 201, 202 and 203, respectively coupled to 
communicate data packets over local area network (LAN) 205. Likewise, the branch 
site 1 10 is shown having a plurality of endstations 21 1, 212 and 213 respectively 
coupled to communicate data locally over LAN 215. Finally, the second branch site 
1 12 is shown with an illustrative set of computer stations 221, 222 and 223 connected 
to communicate over LAN 225. The customer site 140 is also illustrated in Figure 2 
as comprising of plurality of computers illustrated by 331 and 332 coupled to 
20 communicate over the customer's LAN 235. The local area networks utilized for data 
communications within the headquarters, customer and branch sites may adhere to a 
wide variety of network protocols, the most common of which are Ethernet and Token 
Ring. 

As can be seen in Figure 2, the dedicated communications lines between the 
25 headquarters site 105 and the branch sites 1 10 and 1 12 as well as between the 

headquarters site 105 and the customers site 140 have been eliminated. Instead, in 
accordance with the present invention data communications between members of the 
organization arc intended to be carried out over the Internet or other public network 
space. For purposes of the present invention, it will be assumed that it is the widely 
30 emerging Internet that will be the medium for data packet transfers between members 
of the organization. 



15 
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Each of the LANs for the particular sites illustrated in Figure 2 ultimately 
interconnect to the Internet 250 through an associated routing or gateway device 
which are identified as routers 240, 242, 244 and 246, respectively. It is to be 
understood that data packets conveyed between a various sites illustrated in 200 
5 would traverse, in many cases, a plurality of additional routing devices on their way 
between the source and destination sites for the packets. The mechanisms for data 
packet transfers over the Internet are well known and are not described in great detail 
herein. It is understood that data packets are assembled in accordance with the 
Internet Protocol (IP) and are referred to herein as IP packets regardless of the version 
10 of the Internet protocol presently in effect. In the case of the remote clients 150 and 
1 55 illustrated in Figure 2 it is understood that they utilize communication software to 
dial up a local Internet service provider which itself provides the gateways necessary 
for communications over the Internet 250. 

As has been described above, prior efforts to utilize the Internet for secure data 
15 communications have required an awareness or implementation of security 

considerations at the endstations. This is disadvantageous when transparency to an 
end user is desirable. The present invention, on the other hand is transparent to end 
users with data communications over the Internet occurring exactly as they appear to 
have before. However, for users identified as members of the same virtual private 
20 network, data communications are handled in a manner that assures the security and 
integrity of the data packets. Illustrated in Figure 2, between the Internet 250 and 
each of the respective routers 240, 242, 244 and 246, are Virtual Private Network 
Units (VPN Units) 250, 252, 254 and 256. In accordance with the particular 
illustrated embodiment of the present invention, the VPN Units reside between a site's 
25 router and the path to the Internet. It should be understood that this placement of 

VPNU units in the overall system architecture represents only one placement choice. 
It will be clear from the materials that follow that the key point with respect to VPNU 
placement is that they reside in the path of data traffic. In many embodiments, it may 
in fact prove desirable to situate the VPNU on the LAN side of a site's router. As will 
30 be described in more detail below, the VPN Units maintain lookup tables for 
identifying members of specific virtual private network groups. 
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When a data packet is sent between source and destination addresses that are 
both members of the same VPN group, the VPN Unit will process the data packet 
from the sending side in such a way as to ensure that it encrypted, authenticated and 
optionally compressed. Likewise, the VPN Unit servicing the site where the 
5 destination address is located will detect that a packet is being propagated between 
members of the same VPN group. The receiving VPN Unit will handle the process of 
decrypting and authenticating the packet before forwarding it toward the destination 
endstation. In this way, secure data communications between end users is effected in 
a manner that is transparent to the end users. In the case of remote clients 150 and 

10 1 55, the VPN Unit may be simulated in software which operates in conjunction with 
the communication software for connecting the remote client to the associated local 
Internet service provider. 

The functionality of the VPN Units will be described with reference to the 
following figures beginning with the flowchart of Figure 3 . When a data packet 

1 5 originates from an endstation, such as endstation 202 of LAN 205 at site 1 05, and its 
destination is to a remote site, other than the headquarters site 105, it will initially be 
treated as an ordinary Internet data packet transfer. The packet will proceed from the 
endstation 202 over the LAN 205 to the routing device 240 which will encapsulate the 
data packet in accordance with the Internet Protocol, forming an outbound IP packet. 

20 On its way out of the site, the IP packet will pass through the associated VPN Unit for 
the site. The flowchart illustrated at Figure 3 shows the functional operation of a VPN 
Unit for an outbound packet that is received thereby. The Transmit Packet procedure 
300 begins when the outbound data packet is received at the VPN Unit at step 310. At 
decision box 320, it is determined whether or not the source and destination addresses 

25 for the data packet are both members of the same VPN group. This determination 

may be made with reference to lookup tables that are maintained by the VPN Units or 
reference to other memory mechanisms. This step may be thought of as member 
filtering for data packets being transmitted between the particular site and the VPN 
Unit which services it. If the source and destination address for the data packet are 

30 not both members of the same VPN group, then at step 330 the packet is forwarded to 
the Internet as ordinary Internet traffic from the site as though the VPN Unit were not 
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involved. In which case, the procedure ends at step 335. In one alternative 
embodiment, it may be desirable to discard data traffic that is not destined between 
members of a VPN group rather than forwarding it as unsecure traffic. In another 
alternative embodiment, it may be desirable to provide the option to either pass or 
5 discard non-VPN-group data traffic. 

If, at decision box 320, the member filter, it is determined that both the source 
and destination addresses for the data packet are members of the same VPN group, 
then the data packet is processed at step 340 undergoing various combinations of 
compression, encryption and authentication. The lookup tables maintained by the 
10 VPN Unit 250 and all of the VPN Units, in addition to identifying members of 

particular VPN groups, also identify whether or not data packets transferred between 
members of the particular VPN group are to be compressed and if so, what algorithm 
is to be used for compression. Many possible compression algorithms are well- 
known, but in one embodiment of the invention, LZW compression is implemented. 
1 5 The lookup table for the VPN group of which the source and destination addresses are 
members also identifies the particular encryption algorithm to be used for data packets 
traversing the Internet for that VPN group as well as the authentication and key 
management protocol information to be used thereby. As an alternative to lookup 
tables, the VPN Unit may be programmed to always use the same algorithms for all 
20 VPN groups. 

The particular packet processing algorithms to be used for VPN traffic may 
vary, so long as the lookup tables in both the sending and receiving VPN Units 
identify the same compression, encryption and authentication rules and are capable of 
implementing and deimplementing them for members of the same group. It is to be 
25 understood that a single VPN Unit may serve multiple VPN groups and that particular 
addresses may be members of multiple groups. Thus, at step 340, when a packet is 
destined from one member of the VPN group to another, the packet is processed 
according to the compression, encryption and authentication rules identified in the 
VPN Unit tables for that particular VPN group. Then, at step 350, the processed 
30 packet is forwarded toward the destination address over the Internet. The procedure 
of the sending VPN Unit then ends at step 355. 
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The receiving VPN Unit reverses the above processes for VPN traffic as 
illustrated by the flowchart of Figure 4. The Receive Packet procedure 400 begins at 
step 410 when an inbound data packet is received from the Internet at the receiving 
VPN Unit. At decision box 420, the inbound data packet is examined to determine if 
5 the source and destination addresses of the data packet are both members of the same 
VPN group. It is assumed that the lookup tables maintained by all of the VPN Units 
are both consistent and coherent. If the inbound data packet is determined not to be 
VPN traffic, then the packet is passed through and forwarded to the receiving site as 
though it were normal Internet data traffic at step 430. In which case the process ends 
1 0 at step 435. In one alternative embodiment it may be desirable to discard incoming 
data traffic that is not from an identified member of a VPN group supported by the 
VPNU. 

For data packets that are determined to be VPN traffic at decision box 420, the 
VPN Unit will process the inbound packet to recover the original data packet as it was 

1 5 provided from the source endstation. The lookup tabic maintained by the receiving 
VPN Unit will identify the compression, encryption and authentication rules used for 
the VPN group and reconstruct the original IP packet in accordance with those rules at 
step 440. Then, the reconstructed packet will be delivered to the site of the 
destination address at 450 with the procedure ending at step 455. 

20 Figure 5 illustrates graphically the life cycle of the data packet sent between 

two members of the same VPN group. The data packet originates from a source 500 
and propagates from the sources site through its associated router to generate IP data 
packet 510. The data packet 510 is not intended to illustrate all the fields associated 
with a complete IP data packet, but shows the relevant portions for this discussion 

25 which include the destination address, source address and the payload information of 
the packet. The data packet 510 is then examined by the VPN Unit which determines 
whether the data packet is traffic between members of an identified VPN group. The 
VPN Unit 520 processes the packet in accordance with the packet processing 
procedures described above with respect to Figure 3 with the resulting packet being 

30 illustrated as packet 530. Packet 530 still identifies the destination and source 
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addresses of the data packet, but the remainder of the packet is encrypted, and 
optionally compressed. 

Following processing by the outbound VPN Unit, the data packet is 
propagated through the Internet to 550 with the destination and source information 
5 identifying to the associated routers of the Internet the path by which the packet 

should ultimately take to reach its destination. The packet emerges from the Internet 
at the edge of the destination site as data packet 540 which is essentially identical to 
the data packet 530. The packet is "deprocessed" by the receiving VPN Unit 550 
which restores the original packet into its form 560 for delivery to the ultimate 
10 destination through the receiving site's associated router al destination 570. 

As was described above, the present invention approach to virtual private 
networks supports not only optional compression of data packets, but encryption and 
authentication techniques as well. One emerging standard for key management in 
connection with Internet Protocol data transfers with authentication is referred to as 
15 simple key management for Internet Protocol (SKIP) which is described by US Patent 
5,588,060 assigned to Sun Microapparatus, Inc. of Mountain View, CA. 
Authenticated data transfers using SKIP support a mode of data transfer referred to as 
tunnel mode. The above described data transfer with respect to Figure 5 illustrates a 
transport mode of operation in which the data and source addresses are exposed as the 
20 data packet traverses the Internet. In tunnel mode, an added measure of security may 
be provided by encapsulating the entire data packet in another packet which identifies 
the source and destination addresses only for the VPN Units. This conceals the 
ultimate source and destination addresses in transit. 

Figure 6 illustrates the life cycle of a data packet being propagated from a 
25 source 600 to a destination 670 utilizing tunnel mode. In this mode of operation, the 
data packet 610 is processed by outbound VPN Unit 620 which generates a resulting 
packet 630. The resulting packet 630 encrypts and compresses (optionally) not only 
the data payload of the packet, but the destination and source addresses of the 
endstations as well. The encapsulated packet is then provided with an additional 
30 header that identifies that the source of the packet is the outbound VPN Unit 620 and 
that the destination is the inbound VPN Unit 650. Thus, the packet 640 which 
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emerges from the Internet is identical to the packet 630 with respect to its source and 
address information and encapsulated payload. The packet is decomposed by the 
inbound VPN Unit 650 to reconstruct the original data packet at 660 for delivery to 
the destination 670. 

The overall architecture of the present invention is robust. It allows end users 
the convenience of proprietary data communications to take place over a public 
network space such as the Internet. The architecture of the present invention also 
allows a wide variety of compression, encryption and authentication technologies to 
be implemented, so long as the VPN Units at each end of the transaction support the 
associated protocols. The present invention is also capable of working in concert with 
traditional Internet security mechanisms such as corporate firewalls. A firewall might 
operate in series with the VPN Unit at a given site, or. intelligently be configured in a 
single box with the VPN Unit to provide parallel firewall and VPN Unit security 
functions. 

15 Architecture for a Virtu al Private Network Unit 

The above discussion relates to the functionality for implementing virtual 
private networks. There is now described a hardware architecture and implementation 
for a virtual private network unit in accordance with one embodiment of the present 
invention. Referring now to Figure 7 there is illustrated a general block diagram for a 

20 virtual private network unit 700. The general architecture of the VPN Unit 700 is 
essentially that of a specially tailored personal computer (PC) apparatus architecture. 
The overall operation of the VPN Unit 700 is driven by a central processing unit 
(CPU) 705 which is coupled to communicate with the other components of the 
apparatus over a apparatus bus 710. In the general architecture illustrated for VPN 

25 Unit 700. the memory apparatus 720 is also illustrated as residing on the apparatus 
bus 7 1 0. Those of ordinary skill in the art will of course recognize that various 
memory configurations may be implemented, some of which may include a dedicated 
memory bus for higher speed throughput to the memory apparatus 720. 

The VPN Unit 700 is designed to be an intermediate device between a site's 

30 local area network and the Internet or other public network space. Thus, the VPN 

Unit 700 is illustrated as having an I/O controller 730 for coupling the VPN Unit 700 



WSDOCID: <WO 9857464A1, 1 > 



WO 98/57464 



15 



PCT/US98/12226 



to the Internet or other public network space. Similarly, an I/O controller 740 is 
provided for coupling the VPN Unit 700 to the site's edge router. In accordance with 
the above-described functional requirements, the VPN Unit 700 resides between the 
site's router and the Internet. In this implementation, the I/O controller 740 is 
5 responsible for data packet transmissions between the router for the site and the VPN 
Unit 700. In an alternate embodiment of the present invention, the VPN Unit 700 
may be disposed between a site's local area network and its router, in which case the 
I/O controller 730 would be responsible for data packet transmissions between the 
VPN Unit 700 and the router, while the I/O controller 740 would effectively be the 
10 VPN Unit's interface to the local area network. In this alternative embodiment, data 
packet transmissions would probably have to be handled in accordance with the 
network protocol standard of the local area network rather than the public network 
space IP transmissions as described above. In either event, the general architecture for 
VPN Unit 700 illustrates that the two I/O controllers 730 and 740 are coupled to 
1 5 communicate over the apparatus bus 710 through I/O control logic 750. In 
accordance with this architecture, the I/O control logic 750 is responsible for 
arbitrating access to the apparatus bus for the data packets coming in and going out, 
and for assuring the necessary throughput for the data connections. 

As has been described, u'hen a data packet is received at the VPN Unit 700, 
20 whether outbound or inbound, a determination is made by examining the data packet's 
header as to whether or not both the source and destination addresses represent 
members of the same VPN group. The determination with respect to one embodiment 
requires interrogation of a look-up table, which maintains the identities of the various 
VPN groups serviced by the VPN Unit 700, as well as the group members and the 
25 various processing parameters for data packets that are exchanged between group 
members. In accordance with the general architecture of the VPN Unit 700, this 
interrogation may be handled by the CPU 705 with reference to look-up tables that 
would be maintained in the memory apparatus 720. 

For data packets that are to be processed as packets being sent between 
30 members of a supported VPN group, it has been described that compression and 
decompression functions as well as encryption and decryption functions need to be 
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performed for such data. Thus, the VPN Unit 700 architecture includes a compression 
engine 760, coupled to communicate with the rest of the apparatus over the apparatus 
bus 710, and an encryption engine 770 similarly coupled to the apparatus bus 710. 
For supporting functions such as the various key management protocols described 
5 above which result in the generation of packet encapsulation headers, processing may 
be carried out by the CPU 705 with packets being assembled within the CPU 705 or at 
specified memory locations in the memory apparatus 720. Alternatively, logic may be 
incorporated in the VPN Unit 700 designed specifically for the support of such key 
management protocols or other packet processing operations. 

10 There is finally shown in the VPN Unit 700 architecture that optional I/O 

devices 780 may be interfaced to the VPN Unit 700 through I/O control logic 790. 
This may facilitate management of the unit either by allowing direct keyboard access 
to control the processor, or provide axonnection path for other communications 
devices which may need to communicate with the VPN Unit 700. 

1 5 Referring now to Figure 8, there is illustrated a more detailed block diagram 

for one implementation of a VPN Unit in accordance with one embodiment of the 
present invention. In the implemented embodiment of VPN Unit 800 an architecture 
is disclosed which is driven by microprocessor 805, a 100 MHz Intel 486 DX4. The 
apparatus bus for this configuration is the VSIA bus 810 to which the other 

20 components of the apparatus are coupled. The memory apparatus in this case is 

supplied by several banks of fast dynamic random access memory (DRAM) 820. In 
accordance with this implemented embodiment, a PC chip set implementation from 
the Opti Corporation is provided at 825 for controlling the overall operation of the 
apparatus. The Opti chip set, as well as providing a apparatus controller functionality 

25 for the 486 DX4 microprocessor, may also be utilized to provide an interface to an 
optional ISA bus 828 to which other peripherals may be coupled to the apparatus. 

In the implemented VPN Unit 800, the I/O connections to the public network 
space 830 are provided by a series of multi-protocol transceivers with a DB-25 
connector. Similarly, the connections for the private network side of the unit are 

30 provided through additional multi-protocol transceivers and an additional DB-25 
connector. The I/O connections to the public and private networks are handled 
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through a dual-port SCC 845 which includes a plurality of input and output buffers for 
transmission and receipt of data packets to the VPN Unit 800. The data packet I/O 
controller is coupled to the VS1A bus 810 through FPGA Control and Glue Logic 850. 
The compression engine for the implemented VPN Unit 800 is provided by an 

5 implementation of the STAC compression algorithm using the STAC chip 9710 
compression engine 860, which is coupled to a dedicated bank of SRAM 865 to 
support its processing. Finally, in the implemented embodiment the encryption 
engine is provided by a DES engine 870, which may be implemented in either an off- 
the-shelf special integrated circuit configuration or one designed to operate in 

10 accordance with the operation of the VPN Unit 800. In accordance with an alternative 
embodiment of the present invention, it is conceivable that the compression engine 
and encryption engine could be handled by software routines running on the 
microprocessor 805 or other general-purpose processing logic. Other alternative 
embodiments may use later generations of microprocessors which operate at higher 

1 5 speeds and may require implementation of a different apparatus bus such as the 
emerging PCI bus standard. Those of ordinary skill in the art will recognize 
alternative and various embodiments which may be designed to suit a particular 
purpose. 

There has thus been described a protocol and architecture for implementing 
20 virtual private networks for using a public network space for secure private network 
data communications. Although the present invention has been described with respect 
to certain exemplary and implemented embodiments, it should be understood that 
those of ordinary skill in the art will readily appreciate various alternatives to the 
present invention. Accordingly, the spirit and scope of the present invention should 
25 be measured by the terms of the claims which folio w. 
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CLAIMS 

What is claimed is: 



1 1 . An apparatus for providing secured data communications between 

2 members of a virtual private network group comprising: 

3 input/output (I/O) circuitry for receiving and transmitting data packets 

4 between the members of said virtual private network group; 

5 a system bus in communication with said I/O circuitry for conveying data 

6 between components of said system 

7 a compression engine in communication with said system bus for compressing 

8 outbound data packets and decompressing inbound data packets; 

9 an encryption engine in communication with said system bus for encrypting 

1 0 outbound data packets and decrypting inbound data packets; 

1 1 a central processing unit (CPU) in communication with said system bus for 

12 controlling the processing of data packets by said system, said CPU for determining 

1 3 which data packets are being sent between members of said virtual private network 

14 and for determining the data flow for said data packets in accordance with 

1 5 predetermined parameters for said virtual private network; and 

1 6 a memory device in communication with said system bus for maintaining a list 

1 7 of members of said virtual private network and for storing said predetermined 

1 8 parameters. 

1 2. The apparatus of claim 1 wherein said I/O circuitry comprises: 

2 a private I/O port for coupling said apparatus to a site's private network; 

3 a public I/O port for coupling said apparatus to a public network space; and 

4 I/O control logic in communication with said system bus and coupled to said 

5 private and public I/O ports for controlling data packet flow between said apparatus 

6 and said members of said virtual private network. 

1 3. The apparatus of claim 2 wherein said CPU generates encapsulation 

2 headers for outbound data packets in accordance with a key management protocol. 

1 4. The apparatus of claim 3 wherein said key management protocol 

2 comprises the Simple Key Management for Internet Protocol (SKIP). 



*NSDOClD:<WO 9857464A1 \ > 



WO 98/57464 



19 



PCJ7US98/12226 



1 5. The apparatus of claim 2 wherein said encryption engine comprises an 

2 application specific integrated circuit for performing DES encryption. 

1 6. The apparatus of claim 2 wherein said encryption engine comprises an 

2 application specific integrated circuit for performing DES encryption or triple-DES 

3 encryption in accordance with said predetermined parameters. 

1 7. The apparatus of claim 1 wherein said compression engine comprises 

2 an integrated circuit for performing LZW compression. 

1 8. The apparatus of claim 1 wherein said memory comprises lookup 

2 tables for identifying all the virtual private network groups supported by said 

3 apparatus and the members of said group wherein said members are each identified by 

4 a network address and wherein a single network address may identify a member of 

5 multiple groups. 

1 9. An apparatus for securely exchanging data packets between members 

2 of a virtual private network group comprising: 

3 a first computer at a first site, said first computer having a first network 

4 address; 

5 a first router associated with said first site for routing data packets 

6 originating from said first computer over a public network; 

7 a first virtual private network unit disposed between said router and .. 

8 said public network, said first virtual public network unit for identifying virtual 

9 private network group data traffic and for securing said data traffic by manipulating 

10 said data traffic according to packet manipulation rules maintained by said virtual 

1 1 private network unit; 

12 a second router associated with a second site for coupling said second 

1 3 site to the public network; 

14 a second virtual private network unit disposed between said second 

1 5 router and the public network for intercepting network traffic destined for said second 

16 site, said second virtual public network unit for detecting virtual private network 

1 7 group traffic and for recovering original packet data; and 
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1 8 a second computer at said second site, said second computer having a second 

1 9 network address for receiving said packet data, wherein said first and second 

20 virtual private network units respectively comprise: 

21 input/output (I/O) circuitry for receiving and transmitting data packets 

22 between the members of said virtual private network group; 

23 a system bus in communication with said I/O circuitry for conveying data 

24 between components of said apparatus; 

25 a compression engine in communication with said system bus for compressing 

26 outbound data packets and decompressing inbound data packets; 

27 an encryption engine in communication with said system bus for encrypting 

28 outbound data packets and decrypting inbound data packets; 

29 a central processing unit (CPU) in communication with said system bus for 

30 controlling the processing of data packets by said apparatus, said CPU for determining 

3 1 which data packets are being sent between members of said virtual private network 

32 and for determining the data flow for said data packets in accordance with 

33 predetermined parameters for said virtual private network; and 

34 a memory device in communication with said system bus for maintaining a list 

35 of members of said virtual private network and for storing said predetermined 

36 parameters. 

1 10. The system of claim 9 wherein said I/O circuitry comprises: 

2 a private I/O port for coupling said apparatus to a site's private network; 

3 a public I/O port for coupling said apparatus to a public network space; and 

4 I/O control logic in communication with said system bus and coupled to said 

5 private and public I/O ports for controlling data packet flow between said apparatus 

6 and said members of said virtual private network. 

1 11. The system of claim 1 0 wherein said CPU generates encapsulation 

2 headers for outbound data packets in accordance with a key management protocol. 

1 12. The system of claim 1 1 wherein said key management protocol 

2 comprises the Simple Key Management for Internet Protocol (SKIP). 

1 13. The system of claim 1 0 wherein said encryption engine comprises an 

2 application specific integrated circuit for performing DES encryption. 
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1 14. The system of claim 10 wherein said encryption engine comprises an 

2 application specific integrated circuit for performing DIZS encryption or triple-DES 

3 encryption in accordance with said predetermined parameters, 

1 15. The system of claim 10 wherein said compression engine comprises an 

2 integrated circuit for performing LZW compression. 

1 16. A system of claim 10 wherein said memory comprises lookup tables 

2 for identifying all the virtual private network groups supported by said apparatus and 

3 the members of said group wherein said members are each identified by a network 

4 address and wherein a single network address may identify a member of multiple 

5 groups. 
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□ FADED TEXT OR DRAWING 

□ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 

□ LINES OR MARKS ON ORIGINAL DOCUMENT 

□ REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: 

IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 
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